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Abstract 

The  role  of  software  ecosystems  in  the  development  and  evolution  of  open 
architecture  systems  has  received  insufficient  consideration.  Such  systems  are  composed 
of  heterogeneously  licensed  components,  open  source  or  proprietary  or  both,  in  an 
architecture  in  which  evolution  can  occur  by  evolving  existing  components  or  by  replacing 
them.  But  this  may  result  in  possible  license  conflicts  and  organizational  liability  for  failure  to 
fulfill  license  obligations.  We  have  developed  an  approach  for  understanding  and  modeling 
software  licenses,  as  well  as  for  analyzing  conflicts  among  groups  of  licenses  in  realistic 
system  contexts  and  for  guiding  the  acquisition,  integration,  or  development  of  systems  with 
open-source  components  in  such  an  environment.  This  work  is  based  on  empirical  analysis 
of  representative  software  licenses  and  heterogeneously  licensed  systems,  and 
collaboration  with  researchers  in  the  legal  world.  Our  approach  provides  guidance  for 
achieving  a  “best-of-breed”  component  strategy  while  obtaining  desired  license  rights  in 
exchange  for  acceptable  obligations. 

Introduction 

A  substantial  number  of  development  organizations  are  adopting  a  strategy  in  which 
a  software-intensive  system  is  developed  with  an  open  architecture  (OA)  (Oreizy,  2000), 
whose  components  may  be  open  source  software  (OSS)  or  proprietary  with  open 
application  programming  interfaces  (APIs).  Such  systems  evolve  not  only  through  the 
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evolution  of  their  individual  components,  but  also  through  replacement  of  one  component  by 
another,  possibly  from  a  different  producer  or  under  a  different  license.  With  this  approach, 
the  organization  becomes  an  integrator  of  components  largely  produced  elsewhere  that  are 
interconnected  through  open  APIs  as  necessary  to  achieve  the  desired  result.  An  OA 
development  process  results  in  an  ecosystem  in  which  the  integrator  is  influenced  from  one 
direction  by  the  goals,  interfaces,  license  choices,  and  release  cycles  of  the  component 
producers,  and  in  another  direction  by  the  needs  of  its  consumers.  As  a  result,  the  software 
components  are  reused  more  widely,  and  the  resulting  OA  systems  can  achieve  reuse 
benefits  such  as  reduced  costs,  increased  reliability,  and  potentially  increased  agility  in 
evolving  to  meet  changing  needs.  An  emerging  challenge  is  to  realize  the  benefits  of  this 
approach  when  the  individual  components  are  heterogeneously  licensed,  each  potentially 
with  a  different  license  rather  than  a  single  OSS  license  as  in  uniformly  licensed  OSS 
projects,  or  a  single  proprietary  license  when  acquired  from  a  vendor  employing  a 
proprietary  development  scheme. 

This  challenge  is  inevitably  entwined  with  the  software  ecosystems  that  arise  for  OA 
systems.  We  find  that  an  OA  software  ecosystem  involves  not  only  organizations  and 
individuals  producing  and  consuming  components,  and  supply  paths  from  producer  to 
consumer,  but  also: 

■  the  OA  of  the  system(s)  in  question, 

■  the  open  interfaces  met  by  the  components, 

■  the  degree  of  coupling  in  the  evolution  of  related  components,  and 

■  the  rights  and  obligations  resulting  from  the  software  licenses  under  which 
various  components  are  released,  that  propagate  from  producers  to  consumers. 

An  example  software  ecosystem  is  portrayed  in  Figure  1. 

In  order  to  most  effectively  use  an  OA  approach  in  developing  and  evolving  a 
system,  it  is  essential  to  consider  this  OA  ecosystem.  An  OA  system  draws  on  components 
from  proprietary  vendors  and  open  source  projects.  Its  architecture  is  made  possible  by  the 
existing  general  ecosystem  of  producers,  from  which  the  initial  components  are  chosen.  The 
choice  of  a  specific  OA  begins  a  specialized  software  ecosystem  involving  components  that 
meet  (or  can  be  shimmed  to  meet)  the  open  interfaces  used  in  the  architecture.  We  do  not 
claim  this  is  the  best  or  the  only  way  to  reuse  components  or  produce  systems,  but  it  is  an 
ever  more  widespread  way.  In  this  paper,  we  build  on  previous  work  on  heterogeneously 
licensed  systems  (HLSs)  (German  &  Hassan,  2009;  Alspaugh  &  Scacchi,  2008;  Alspaugh, 
Asuncion  &  Scacchi,  2009a,  May)  by  examining  the  role  of  component  licenses  in  OA 
software  ecosystems  and  how  OA  development  affects  and  is  affected  by  software 
ecosystems. 

A  motivating  example  of  this  approach  is  the  Unity  game  development  tool,  produced 
by  Unity  Technologies  (Unity  Technologies,  2008),  which  can  be  used  to  create  game- 
based  virtual  worlds  for  training  applications.  Its  license  agreement,  which  we  quote  below, 
lists  eleven  distinct  licenses  and  indicates  the  tool  is  produced,  apparently  using  an  OA 
approach,  using  at  least  18  externally  produced  components  or  groups  of  components: 
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Figure  1.  An  Example  of  a  Software  Ecosystem  in  which  OA  Systems  Are  Developed 


1. 


The  Mono  Class  Library,  Copyright  2005-2008  Novell,  Inc. 

1 .  The  Mono  Runtime  Libraries,  Copyright  2005-2008  Novell,  Inc. 

Boo,  Copyright  2003-2008  Rodrigo  B.  Oliveira. 

UnityScript,  Copyright  2005-2008  Rodrigo  B.  Oliveira. 

OpenAL  cross  platform  audio  library.  Copyright  1999-2006  by  authors. 


2. 

3. 

4. 

5. 


PhysX  physics  library.  Copyright  2003-2008  by  Ageia  Technologies, 
Inc. 

6.  libvorbis.  Copyright  (c)  2002-2007  Xiph.org  Foundation. 

7.  libtheora.  Copyright  (c)  2002-2007  Xiph.org  Foundation. 

8.  zlib  general  purpose  compression  library.  Copyright  (c)  1995-2005 
Jean-loup  Gailly  and  Mark  Adler. 

9.  libpng  PNG  reference  library. 
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10.  jpeglib  JPEG  library.  Copyright  (C)  1991-1998,  Thomas  G.  Lane. 

1 1 .  Twilight  Prophecy  SDK,  a  multi-platform  development  system  for 
virtual  reality  and  multimedia.  Copyright  1997-2003  Twilight  3D 
Finland  Oy  Ltd. 

12.  dynamic  bitset.  Copyright  Chuck  Allison  and  Jeremy  Siek  2001-2002. 

13.  The  Mono  C#  Compiler  and  Tools,  Copyright  2005-2008  Novell,  Inc. 

14.  libcurl.  Copyright  (c)  1996-2008,  Daniel  Stenberg  <daniel@haxx.se>. 

15.  PostgreSQL  Database  Management  System. 

16.  FreeType.  Copyright  (c)  2007  The  FreeType  Project 
(www.freetype.org). 

17.  NVIDIA  Cg.  Copyright  (c)  2002-2008  NVIDIA  Corp. 

An  OA  system  can  evolve  by  a  number  of  distinct  mechanisms,  some  of  which  are 
common  to  all  systems  and  others  of  which  are  a  result  of  heterogeneous  component 
licenses  in  a  single  system. 

By  component  evolution — One  or  more  components  can  evolve,  altering  the  overall 
system’s  characteristics  (for  example,  upgrading  and  replacing  the  Firefox  Web  browser 
from  version  3.5  to  3.6). 

By  component  replacement — One  or  more  components  may  be  replaced  by  others 
with  different  behaviors  but  the  same  interface,  or  with  a  different  interface  and  the  addition 
of  shim  code  to  make  it  match  (for  example,  replacing  the  AbiWord  word  processor  with 
either  Open  Office  or  MS  Word). 

By  architecture  evolution — The  OA  can  evolve,  using  the  same  components  but  in  a 
different  configuration,  altering  the  system  characteristics.  For  example,  as  discussed  in 
Section  4,  changing  the  configuration  in  which  a  component  is  connected  can  change  how 
its  license  affects  the  rights  and  obligations  for  the  overall  system.  This  could  arise  when 
replacing  email  and  word  processing  applications  with  web  services  like  Google  Mail  and 
Google  Docs. 

By  component  license  evolution — The  license  under  which  a  component  is  available 
may  change  (for  example,  when  the  license  for  the  Mozilla  core  components  was  changed 
from  the  Mozilla  Public  License  (MPL)  to  the  current  Mozilla  Disjunctive  Tri-License),  or  the 
component  may  be  made  available  under  a  new  version  of  the  same  license  (for  example, 
when  the  GNU  General  Public  License  (GPL)  version  3  was  released). 

By  a  change  to  the  desired  rights  or  acceptable  obligations — The  OA  system’s 
integrator  or  consumers  may  desire  additional  license  rights  (for  example,  the  right  to 
sublicense  in  addition  to  the  right  to  distribute)  or  no  longer  desire  specific  rights  or  the  set  of 
license  obligations  they  find  acceptable  may  change.  In  either  case,  the  OA  system  evolves, 
whether  by  changing  components,  evolving  the  architecture,  or  by  other  means,  to  provide 
the  desired  rights  within  the  scope  of  the  acceptable  obligations.  For  example,  they  may  no 
longer  be  willing  or  able  to  provide  the  source  code  for  components  within  the  reciprocality 
scope  of  a  GPL-licensed  module. 

The  interdependence  of  integrators  and  producers  results  in  a  co-evolution  of 
software  within  an  OA  ecosystem.  Closely  coupled  components  from  different  producers 
must  evolve  in  parallel  in  order  for  each  to  provide  its  services,  as  evolution  in  one  will 
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typically  require  a  matching  evolution  in  the  other.  Producers  may  manage  their  evolution 
with  a  loose  coordination  among  releases,  for  example  like  that  between  the  Gnome  and 
Mozilla  organizations.  Each  release  of  a  producer  component  creates  a  tension  through  the 
ecosystem  relationships  with  consumers  and  their  releases  of  OA  systems  using  those 
components,  as  integrators  accommodate  the  choices  of  available,  supported  components 
with  their  own  goals  and  needs.  As  discussed  in  our  previous  work  (Alspaugh  et  al.,  2009a, 
May),  license  rights  and  obligations  are  manifested  at  each  component  interface  then 
mediated  through  the  OA  of  the  system  to  entail  the  rights  and  corresponding  obligations  for 
the  system  as  a  whole.  As  a  result,  integrators  must  frequently  re-evaluate  the  OA  system 
rights  and  obligations.  In  contrast  to  homogeneously  licensed  systems,  license  change 
across  versions  is  a  characteristic  ofOA  ecosystems,  and  architects  of  OA  systems  require 
tool  support  for  managing  the  ongoing  licensing  changes. 

We  propose  that  such  support  must  have  several  characteristics.  It  must  rest  on  a 
license  structure  of  rights  and  obligations  (section  5),  focusing  on  obligations  that  are 
enactable  (it  can  be  put  into  practice)  and  testable.  For  example,  many  OSS  licenses 
include  an  obligation  to  make  a  component’s  modified  code  public,  and  whether  a  specific 
version  of  the  code  is  public  at  a  specified  Web  address  is  both  enactable  and  testable.  In 
contrast,  the  GPL  v.3  provision  “No  covered  work  shall  be  deemed  part  of  an  effective 
technological  measure  under  any  applicable  law  fulfilling  obligations  under  article  1 1  of  the 
WlPO  copyright  treaty”  is  not  enactable  in  any  obvious  way,  nor  is  it  testable — how  can  one 
verify  what  others  deem? 

■  It  must  take  account  of  the  distinctions  between  the  design-time,  build-time,  and 
distribution-time  architectures  (sections  4,  5,  6)  and  the  rights  and  obligations 
that  come  into  play  for  each  of  them. 

■  It  must  distinguish  the  architectural  constructs  significant  for  software  licenses 
and  embody  their  effects  on  rights  and  obligations  (section  4). 

■  It  must  define  license  architectures  (section  6). 

■  It  must  provide  an  automated  environment  for  creating  and  managing  license 
architectures.  We  are  developing  a  prototype  that  manages  a  license’s 
architecture  as  a  view  of  its  system  architecture  (Alspaugh  et  al.,  2009a,  May). 

■  Finally,  it  must  automate  calculations  on  system  rights  and  obligations  so  that 
they  may  be  done  easily  and  frequently,  whenever  any  of  the  factors  affecting 
rights  and  obligations  may  have  changed  (Section  7). 

In  the  remainder  of  this  paper,  we  survey  some  related  work  (section  2),  provide  an 
overview  of  OSS  licenses  and  projects  (section  3),  define  and  examine  characteristics  of 
open  architectures  (section  4),  introduce  a  structure  for  licenses  (section  5),  outline  license 
architectures  (section  6),  and  sketch  our  approach  for  license  analysis  (section  7).  We  then 
close  with  a  discussion  addressing  how  our  software  license  and  analysis  scheme  relates  to 
software  products  lines  and  to  specification  of  software  system  security  requirements 
(section  8)  before  stating  our  conclusions  (section  9). 

Related  Work 

It  has  been  typical  until  recently  for  each  software  or  information  system  to  be 
designed,  built,  and  distributed  under  the  terms  of  a  single  proprietary  or  OSS  license,  with 
all  its  components  homogeneously  covered  by  that  same  license.  The  system  is  distributed 
with  sources  or  executables  bearing  copyright  and  license  notices,  and  the  license  gives 
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specific  rights  while  imposing  corresponding  obligations  that  system  consumers  (whether 
external  developers  or  users)  must  honor,  subject  to  the  provisions  of  contract  and 
commercial  law.  Consequently,  there  has  been  some  very  interesting  study  of  the  choice  of 
OSS  license  for  use  in  an  OSS  development  project,  and  its  consequences  in  determining 
the  likely  success  of  such  a  project. 

Brown  and  Booch  (2002)  discuss  issues  that  arise  in  the  reuse  of  OSS  components, 
such  as  interdependence  (via  component  interconnection  at  design-time  or  linkage  at  build¬ 
time  or  run-time)  causing  functional  changes  to  propagate  and  versions  of  the  components 
evolving  asynchronously,  giving  rise  to  co-evolution  of  interrelated  code  in  the  OSS-based 
systems.  If  the  components  evolve,  the  OA  system  itself  is  evolving.  The  evolution  can  also 
include  changes  to  the  licenses,  and  the  licenses  can  change  from  component  version  to 
version  (cf.  Footnote  1). 

Legal  scholars  have  examined  OSS  licenses  and  how  they  interact  in  the  legal 
domain  but  not  in  the  context  of  HLSs  (Fontana  et  al.,  2008;  Rosen,  2005;  St.  Laurent, 

2004).  For  example,  Rosen  surveys  eight  OSS  licenses  and  creates  two  new  ones  written  to 
professional  legal  standards.  He  examines  interactions  primarily  in  terms  of  the  general 
categories  of  reciprocal  and  non-reciprocal  licenses,  rather  than  in  terms  of  specific  licenses. 
However,  common  to  this  legal  scholarship  is  an  approach  that  analyzes  the  interaction 
among  licenses  on  a  pair-wise  or  interlinked  components  basis.  This  analysis  scheme 
means  that  if  system  A  has  OSS  license  of  type  X,  system  B  has  a  licenses  of  type  Y,  and 
system  C  has  license  of  type  Z,  then  license  interaction  (matching,  subsumption,  or 
conflicting  constraints)  is  determined  by  how  A  interacts  with  B,  B  with  C,  and  A  with  C.  This 
follows  from  related  legal  scholarship  (e.g.,  Burk,  1998)  that  brought  attention  to  problems  of 
whether  or  not  intellectual  property  rights  apply  depending  on  how  the  systems  (or 
components)  are  interlinked  (cf.,  German  and  Hassan,  2009).  We  similarly  adopt  this 
approach  in  our  analysis  efforts. 

Stewart,  Ammeter,  and  Maruping  (2006)  conducted  an  empirical  study  to  examine 
whether  license  choice  is  related  to  OSS  project  success,  finding  a  positive  association 
following  from  the  selection  of  business-  friendly  licenses.  Sen,  Subramaniam,  and  Nelson 
in  a  series  of  studies  (2007  &  2009)  similarly  find  positive  relationships  between  the  choice 
of  a  OSS  license  and  the  likelihood  of  both  successful  OSS  development  and  adoption  of 
corresponding  OSS  systems  within  enterprises.  These  studies  direct  attention  to  OSS 
projects  that  adopt  and  identify  their  development  efforts  through  use  of  a  single  OSS 
license.  However,  there  has  been  little  explicit  guidance  on  how  best  to  develop,  deploy,  and 
sustain  complex  software  systems  when  heterogeneously  licensed  components  are 
involved,  and  thus  multiple  OSS  and  proprietary  licenses  may  be  involved.  Ven  and 
Mannaert  (2008);  Tuunanen,  Koskinen,  and  Karkkainen  (2009);  and  German  and  Hassan 
(2009)  are  recent  exceptions. 

Ven  and  Mannaert  discuss  the  challenges  faced  by  independent  software  vendors 
developing  an  HLS.  They  focus  on  the  evolution  and  maintenance  of  modified  OSS 
components.  Tuunanen,  Koskinen,  and  Karkkainen  exemplify  most  work  to  date  on  HLSs, 
in  that  they  focus  on  reverse  engineering  and  recovery  of  individual  component  licenses  on 
existing  systems,  rather  than  on  guiding  HLS  design  to  achieve  and  verify  desired  license 
outcomes.  Their  approach  does  not  support  the  calculation  of  HLS  virtual  licenses.  German 
and  Hassan  model  a  license  as  a  set  of  grants,  each  of  which  has  a  set  of  conjoined 
conditions  necessary  for  the  grant  to  be  given.  They  analyze  interactions  between  pairs  of 
licenses  in  the  context  of  five  types  of  component  connection.  They  also  identify  twelve 
patterns  for  avoiding  license  mismatches,  found  in  an  empirical  study  of  a  large  group  of 
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OSS  projects,  and  characterize  the  patterns  using  their  model.  Our  license  model  extends 
German  and  Hassan’s  to  address  semantic  connections  between  obligations  and  rights  we 
find  through  a  textual  analysis  of  OSS  licenses. 

Other  previous  work  examined  how  best  to  align  acquisition,  system  requirements, 
architectures,  and  OSS  components  across  different  software  license  regimes  to  achieve 
the  goal  of  combining  OSS  with  proprietary  software  that  provide  open  APIs  when 
developing  a  composite  “system  of  systems”  (Scacchi  &  Alspaugh,  2008).  This  is  particularly 
an  issue  for  the  US  Federal  Government  in  its  acquisition  of  complex  software  systems 
subject  to  Federal  Acquisition  Regulations  (FARs)  and  military  service-  specific  regulations. 
HLSs  give  rise  to  new  functional  and  non-functional  requirements  that  further  constrain  what 
kinds  of  systems  can  be  built  and  deployed,  as  well  as  recognizing  that  acquisition  policies 
can  effectively  exclude  certain  OA  configurations  while  accommodating  others,  based  on 
how  different  licensed  components  may  be  interconnected. 

Open  Source  Software 

Traditional  proprietary  licenses  allow  a  company  to  retain  control  of  software  it 
produces  and  to  restrict  the  access  and  rights  that  outsiders  can  have.  OSS  licenses,  on  the 
other  hand,  are  designed  to  encourage  sharing  and  reuse  of  software,  and  grant  access  and 
as  many  rights  as  possible.  OSS  licenses  are  classified  as  academic  or  reciprocal. 

Academic  OSS  licenses  such  as  the  Berkeley  Software  Distribution  (BSD)  license,  the 
Massachusetts  Institute  of  Technology  license,  the  Apache  Software  License,  and  the 
Artistic  License  grant  nearly  all  rights  to  components  and  their  source  code  and  impose  few 
obligations.  Anyone  can  use  the  software,  create  derivative  works  from  it,  or  include  it  in 
proprietary  projects.  Typical  academic  obligations  are  simply  to  not  remove  the  copyright 
and  license  notices. 

Reciprocal  OSS  licenses  take  a  more  active  stance  towards  sharing  and  reusing 
software  by  imposing  the  obligation  that  reciprocally  licensed  software  not  be  combined  (for 
various  definitions  of  “combined”)  with  any  software  that  is  not  in  turn  also  released  under 
the  reciprocal  license.  The  goals  are  to  increase  the  domain  of  OSS  by  encouraging 
developers  to  bring  more  components  under  its  aegis  and  to  prevent  improvements  to  OSS 
components  from  vanishing  behind  proprietary  licenses.  Example  reciprocal  licenses  are 
GPL,  the  Mozilla  Public  License  (MPL),  and  the  Common  Public  License. 

Both  proprietary  and  OSS  licenses  typically  disclaim  liability,  assert  no  warranty  is 
implied,  and  obligate  licensees  to  not  use  the  licensor’s  name  or  trademarks.  Newer 
licenses  often  cover  patent  issues  as  well,  either  giving  a  restricted  patent  license  or 
explicitly  excluding  patent  rights. 

The  Mozilla  Disjunctive  Tri-License  licenses  the  core  Mozilla  components  under  any 
one  of  three  licenses  (MPL,  GPL,  or  the  GNU  Lesser  General  Public  License  LGPL).  OSS 
developers  can  choose  the  one  that  best  suits  their  needs  for  a  particular  project  and 
component. 

The  Open  Source  Initiative  (OSI)  maintains  a  widely  respected  definition  of  “open 
source”  and  gives  its  approval  to  licenses  that  meet  it  (Open  Source  Initiative,  2008).  OSI 
maintains  and  publishes  a  repository  of  approximately  70  approved  OSS  licenses. 

Common  practice  has  been  for  an  OSS  project  to  choose  a  single  license  under 
which  all  its  products  are  released  and  to  require  developers  to  contribute  their  work  only 
under  conditions  compatible  with  that  license.  For  example,  the  Apache  Contributor  License 
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Agreement  grants  enough  of  each  author’s  rights  to  the  Apache  Software  Foundation  for  the 
foundation  to  license  the  resulting  systems  under  the  Apache  Software  License.  This  sort  of 
rights  regime,  in  which  the  rights  to  a  system’s  components  are  homogeneously  granted  and 
the  system  has  a  single  well-defined  OSS  license,  was  the  norm  in  the  early  days  of  OSS 
and  continues  to  be  practiced. 

Open  Architecture 

Open  architecture  (OA)  software  is  a  customization  technique  introduced  by  Oreizy 
(2000)  that  enables  third  parties  to  modify  a  software  system  through  its  exposed 
architecture,  evolving  the  system  by  replacing  its  components.  Increasingly  more  software¬ 
intensive  systems  are  developed  using  an  OA  strategy,  not  only  with  OSS  components  but 
also  proprietary  components  with  open  APIs  (Unity  Technologies,  2008).  Using  this 
approach  can  lower  development  costs  and  increase  reliability  and  function  (Scacchi  & 
Alspaugh,  2008).  Composing  a  system  with  HLS  components,  however,  increases  the 
likelihood  of  conflicts,  liabilities,  and  no-rights  stemming  from  incompatible  licenses.  Thus,  in 
our  work  we  define  an  OA  system  as  a  software  system  consisting  of  components  that  are 
either  open  source  or  proprietary  with  open  API,  whose  overall  system  rights  at  a  minimum 
allow  its  use  and  redistribution  in  full  or  in  part. 

It  may  appear  that  using  a  system’s  architecture  that  incorporate  OSS  components 
and  uses  open  APIs  will  result  in  an  OA  system.  But  not  all  such  architectures  will  produce 
an  OA,  since  the  (possibly  empty)  set  of  available  license  rights  for  an  OA  system  depends 
on  (a)  how  and  why  OSS  and  open  APIs  are  located  within  the  system  architecture,  (b)  how 
OSS  and  open  APIs  are  implemented,  embedded,  or  interconnected,  and  (c)  the  degree  to 
which  the  licenses  of  different  OSS  components  encumber  all  or  part  of  a  software  system’s 
architecture  into  which  they  are  integrated  (Alspaugh  &  Anton,  n.d.;  Scacchi  &  Alspaugh, 
2008). 

The  following  kinds  of  software  elements  appearing  in  common  software 
architectures  can  affect  whether  the  resulting  systems  are  open  or  closed  (Bass,  Clements 
&  Kazman,  2003). 

Software  source  code  components — These  can  be  either  (a)  standalone  programs, 
(b)  libraries,  frameworks,  or  middleware,  (c)  inter-application  script  code  such  as  C  shell 
scripts,  or  (d)  intra-application  script  code,  as  for  creating  Rich  Internet  Applications  using 
domain-specific  languages  such  as  XUL  for  the  Firefox  Web  browser  (Feldt,  2007)  or 
“mashups”  (Nelson  &  Churchill,  2006).  Their  source  code  is  available  and  they  can  be 
rebuilt.  Each  may  have  its  own  distinct  license. 
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Executable  components — These  components  are  in  binary  form,  and  the  source  code  may 
not  be  open  for  access,  review,  modification,  or  possible  redistribution  (Rosen,  2005).  If 
proprietary,  they  often  cannot  be  redistributed,  and  so  such  components  will  be  present  in 
the  design-  and  run-time  architectures  but  not  in  the  distribution-time  architecture. 

Software  services — ^An  appropriate  software  service  can  replace  a  source  code  or 
executable  component. 


Figure  2.  A  Heterogeneously  Licensed  System  Composed  from  Multiple 

Systems 


Application  programming  interfaces/APIs — ^Availability  of  externally  visible  and 
accessible  APIs  is  the  minimum  requirement  for  an  open  system  (Meyers  &  Oberndorf, 
2001).  APIs  are  not  and  cannot  be  licensed  and  can  limit  the  propagation  of  license 
obligations. 

Software  connectors — Software  whose  intended  purpose  is  to  provide  a  standard  or 
reusable  way  of  communication  through  common  interfaces,  e.g..  High  Level  Architecture 
(Kuhl,  Weatherly  &  Dahmann,  1999),  CORBA,  MS.NET,  Enterprise  Java  Beans,  and  GNU 
Lesser  General  Public  License  (LGPL)  libraries.  Connectors  can  also  limit  the  propagation 
of  license  obligations. 

Methods  of  connection — These  include  linking  as  part  of  a  configured  subsystem, 
dynamic  linking,  and  client-server  connections.  Methods  of  connection  affect  license 
obligation  propagation,  with  different  methods  affecting  different  licenses. 

Configured  system  or  subsystem  architectures — These  are  software  systems  that 
are  used  as  atomic  components  of  a  larger  system  and  whose  internal  architecture  may 
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comprise  components  with  different  licenses,  affecting  the  overall  system  license.  To 
minimize  license  interaction,  a  configured  system  or  sub-architecture  may  be  surrounded  by 
what  we  term  a  license  firewall,  namely  a  layer  of  dynamic  links,  client-server  connections, 
license  shims,  or  other  connectors  that  block  the  propagation  of  reciprocal  obligations. 

Figure  3  shows  a  high-level  view  of  a  reference  architecture  that  includes  all  the 
kinds  of  software  elements  listed  above.  This  reference  architecture  has  been  instantiated  in 
a  number  of  configured  systems  that  combine  OSS  and  closed  source  components.  One 
such  system  handles  time  sheets  and  payroll  at  our  university;  another  implements  the  web 
portal  for  a  university  computer  game  research  laboratory  (the  updated  version  now  at 
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Figure  4.  A  Build-time  Architecture  Describing  the  Version  Running  in 

Figure  2 

(Note:  Components  or  connectors  not  visible  in  Figure  2  are  shown  in  gray.) 


Figure  5.  Instantiated  Build-time  Architecture  (Figure  4)  within  ArchStudio 


The  configured  systems  consist  of  software  components  such  as  a  Mozilla  Web 
browser,  Gnome  Evolution  email  client,  and  AbiWord  word  processor  (similar  to  MS  Word), 
all  running  on  a  RedHat  Fedora  Linux  operating  system  accessing  file,  print,  and  other 
remote  networked  servers  such  as  an  Apache  Web  server.  Components  are  interconnected 
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through  a  set  of  software  connectors  that  bridges  the  interfaces  of  components  and 
combines  the  provided  functionality  into  the  system’s  services. 

Software  Licenses 

Copyright  law  is  the  common  basis  for  software  licenses  and  gives  the  original 
author  of  a  work  certain  exclusive  rights:  the  rights  to  use,  copy,  modify,  merge,  publish, 
distribute,  sub-license,  and  sell  copies.  The  author  may  license  these  rights,  individually  or 
in  groups,  to  others;  the  license  may  give  a  right  either  exclusively  or  non-exclusively.  After  a 
period  of  years,  copyright  rights  enter  the  public  domain.  Until  then,  copyright  may  only  be 
obtained  through  licensing. 

Licenses  typically  impose  obligations  that  must  be  met  in  order  for  the  licensee  to 
realize  the  assigned  rights.  Common  obligations  include  the  obligation  to  publish  at  no  cost 
any  source  code  you  modify  (MPL)  or  the  reciprocal  obligation  to  publish  all  source  code 
included  at  build-time  or  statically  linked  (GPL).  The  obligations  may  conflict,  as  when  a 
GPL’d  component’s  reciprocal  obligation  to  publish  source  code  of  other  components  is 
combined  with  a  proprietary  component’s  license  prohibition  of  publishing  its  source  code.  In 
this  case,  no  rights  may  be  available  for  the  system  as  a  whole,  not  even  the  right  of  use, 
because  the  two  obligations  cannot  simultaneously  be  met  and  thus  neither  component  can 
be  used  as  part  of  the  system. 

The  basic  relationship  between  software  license  rights  and  obligations  can  be 
summarized  as  follows:  if  the  specified  obligations  are  met,  then  the  corresponding  rights 
are  granted.  For  example,  if  you  publish  your  modified  source  code  and  sub-licensed 
derived  works  under  MPL,  then  you  get  all  the  MPL  rights  for  both  the  original  and  the 
modified  code.  However,  license  details  are  complex,  subtle,  and  difficult  to  comprehend 
and  track.  So  it  is  easy  to  become  confused  or  make  mistakes.  The  challenge  is  multiplied 
when  dealing  with  configured  system  architectures  that  compose  a  large  number  of 
components  with  heterogeneous  licenses,  so  the  need  for  legal  counsel  begins  to  seem 
inevitable  (Rosen,  2005;  Fontana  et  al.,  2008). 

We  have  developed  an  approach  for  expressing  software  licenses  that  is  more 
formal  and  less  ambiguous  than  natural  language  and  that  allows  us  to  calculate  and 
identify  conflicts  arising  from  the  rights  and  obligations  of  two  or  more  component’s  licenses. 
Our  approach  is  based  on  Hohfeld’s  classic  group  of  eight  fundamental  jural  relations 
(1913),  of  which  we  use  right,  duty,  no-right,  and  priviiege.  We  start  with  a  tuple  <actor, 
operation,  action,  object>  for  expressing  a  right  or  obligation.  The  actor  is  the  “licensee” 
for  all  the  licenses  we  have  examined.  The  operation  is  one  of  the  following:  “may,”  “must,” 
“must  not,”  or  “need  not,”  with  “may”  and  “need  not”  expressing  rights  and  “must”  and  “must 
not”  expressing  obligations.  Because  copyright  rights  are  only  available  to  entities  that  have 
been  granted  a  sublicense,  only  the  listed  rights  are  available,  and  the  absence  of  a  right 
means  that  it  is  not  available.  The  action  is  a  verb  or  verb  phrase  describing  what  may, 
must,  must  not,  or  need  not  be  done,  with  the  object  completing  the  description.  A  license 
may  be  expressed  as  a  set  of  rights,  with  each  right  associated  with  zero  or  more 
obligations  that  must  be  fulfilled  in  order  to  enjoy  that  right.  Figures  6,  7,  and  8  show  the 
meta-model  we  use  to  express  licenses,  with  the  allowed  combinations  of  modality,  object, 
and  license  shown  in  Figure  6. 
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Figure  6.  License  Meta-model 

HLS  designers  have  developed  a  number  heuristics  to  guide  architectural  design 
while  avoiding  some  license  conflicts.  First,  it  is  possible  to  use  a  reciprocally  licensed 
component  through  a  license  firewall  that  limits  the  scope  of  reciprocal  obligations.  Rather 
than  connecting  conflicting  components  directly  through  static  or  other  build-time  links,  the 
connection  is  made  through  a  dynamic  link,  client-server  protocol,  license  shim  (such  as  a 
Limited  General  Public  License  connector),  or  run-time  plug-ins.  A  second  approach  used 
by  a  number  of  large  organizations  is  simply  to  avoid  using  any  components  with  reciprocal 
licenses.  A  third  approach  is  to  meet  the  license  obligations  (if  that  is  possible)  by  for 
example  retaining  copyright  and  license  notices  in  the  source  and  publishing  the  source 
code.  However,  even  using  design  heuristics  such  as  these  (and  there  are  many),  keeping 
track  of  license  rights  and  obligations  across  components  that  are  interconnected  in 
complex  OAs  quickly  becomes  too  cumbersome.  Automated  support  is  needed  to  manage 
the  multi-component,  multi-license  complexity. 
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Figure  8.  The  License  Architecture  Meta-modei 


License  Architectures 

Our  license  model  forms  a  basis  for  effective  reasoning  about  licenses  in  the  context 
of  actual  systems  and  calculating  the  resulting  rights  and  obligations.  In  order  to  do  so,  we 
need  a  certain  amount  of  information  about  the  system’s  configuration  at  design-,  build-, 
distribution-,  and  run-time.  The  needed  information  comprises  the  license  architecture,  an 
abstraction  of  the  system  architecture  of  its: 

2.  set  of  components  of  the  system. 


18.  relation  mapping  each  component  to  its  license, 

19.  relation  mapping  each  component  to  its  set  of  sources,  and 

20.  relation  from  each  component  to  the  set  of  components  in  the  same 
license  scope,  for  each  license  for  which  “scope”  is  defined  (e.g., 
GPL)  and  from  each  source  to  the  set  of  sources  of  components  in 
the  scope  of  its  component. 


With  this  information  and  definitions  of  the  licenses  involved,  for  example,  as  seen  in 
Figure  9,  we  calculate  rights  and  obligations  for  individual  components  or  the  entire  system 
and  guide  heterogeneous  license  matching  across  components,  as  shown  in  Figure  10. 
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Figure  9.  License  Annotation  of  Gnome  Evolution  Component 
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License  Analysis 

Given  a  specification  of  a  software  system’s  architecture,  we  can  associate  software 
license  attributes  with  the  system’s  components,  connectors,  and  sub-system  architectures, 
resulting  in  a  license  architecture  for  the  system,  and  calculate  the  copyright  rights  and 
obligations  for  the  system’s  configuration.  Due  to  the  complexity  of  license  architecture 
analysis  and  the  need  to  re-analyze  every  time  a  component  evolves,  a  component’s  license 
changes,  a  component  is  substituted,  or  the  system  architecture  changes,  OA  integrators 
really  need  an  automated  license  architecture  analysis  environment.  We  are  developing  a 
prototype  of  such  an  environment  (Alspaugh  et  al.,  2009a,  May). 

We  use  an  architectural  description  language  specified  in  xADL  (Institute  for 
Software  Research,  2009)  to  describe  OAs  that  can  be  designed  and  analyzed  with  a 
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software  architecture  design  environment  (Medvidovic,  Rosenblum  &  Taylor,  1999),  such  as 
ArchStudio4  (Institute  for  Software  Research,  2006).  We  have  built  the  Software 
Architecture  License  Analysis  module  on  top  of  ArchStudio’s  Traceability  View  (Asuncion  & 
Taylor,  2009).  This  allows  for  the  specification  of  licenses  as  a  list  of  attributes  (license 
tuples)  using  a  form-based  user  interface  in  ArchStudio4  (Medvidovic,  et  al.,  1999;  Institute 
for  Software  Research,  2006).  We  analyze  rights  and  obligations  as  described  below 
(Alspaugh  et  al.,  2009a,  May)  and  as  shown  above  in  Figures  9  and  10. 

Propagation  of  Reciprocal  Obligations 

We  follow  the  widely  accepted  interpretation  that  build-time  static  linkages  propagate 
the  reciprocal  obligations,  but  appropriate  license  firewalls  do  not.  Analysis  begins, 
therefore,  by  propagating  these  obligations  along  all  connectors  that  are  not  license 
firewalls. 

Obligation  Conflicts 

An  obligation  can  conflict  with  another  obligation  or  with  the  set  of  available  rights  by 
requiring  a  copyright  right  that  has  not  been  granted.  For  instance,  a  proprietary  license  may 
require  that  a  licensee  must  not  redistribute  source  code,  but  GPL  states  that  a  licensee 
must  redistribute  source  code.  Thus,  the  conflict  appears  in  the  modality  of  the  two 
otherwise  identical  obligations,  “must  not”  in  the  proprietary  license  and  “must”  in  GPL. 

Rights  and  Obligations  Calculations 

The  rights  available  for  the  entire  system  (use,  copy,  modify,  etc.)  are  calculated  as 
the  intersection  of  the  sets  of  rights  available  for  each  component  of  the  system.  If  a  conflict 
is  found  involving  the  obligations  and  rights  of  linked  components,  it  is  possible  for  the 
system  architect  to  consider  an  alternative  linking  scheme,  e.g.,  using  one  or  more 
connectors  along  the  paths  between  the  components  that  act  as  a  license  firewall.  This 
means  that  the  architecture  and  the  automated  environment  together  can  determine  what 
OA  design  best  meets  the  problem  at  hand  with  available  software  components. 
Components  with  conflicting  licenses  do  not  need  to  be  arbitrarily  excluded  but  instead  may 
expand  the  range  of  possible  architectural  alternatives  if  the  architect  seeks  such  flexibility 
and  choice. 

Discussion 

At  least  two  topics  merit  discussion  following  from  our  approach  to  semantically 
modeling  and  analyzing  OA  systems  that  are  subject  to  heterogeneous  software  licenses. 
One  is  how  our  results  might  shed  light  on  software  systems  whose  architectures  articulate 
a  software  product  line,  while  the  other  is  how  our  approach  might  be  extended  to  also 
address  the  semantic  modeling  and  analysis  of  software  system  security  requirements. 

First,  organizing  and  developing  software  product  lines  (SPLs)  relies  on  the 
development  and  use  of  explicit  software  architectures  (Bosch,  2000;  Clements  &  Northrop, 
2001).  However,  the  architecture  of  a  SPL  is  not  necessarily  an  OA — there  is  no 
requirement  for  it  to  be  so.  Thus,  we  are  interested  in  discussing  what  happens  when  SPLs 
may  conform  to  an  OA,  and  to  an  OA  that  may  be  subject  to  heterogeneously  licensed  SPL 
components.  Three  considerations  come  to  mind.  If  the  SPL  is  subject  to  a  single 
homogeneous  software  license,  which  may  often  be  the  case  when  a  single  vendor  or 
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government  contractor  has  developed  the  SPL,  then  the  license  may  act  to  reinforce  a 
vendor  lock-in  situation  with  its  customers.  One  of  the  motivating  factors  for  OA  is  the  desire 
to  avoid  such  lock-in,  whether  or  not  the  SPL  components  have  open  or  standards- 
compliant  APIs.  Alternatively,  if  an  OA  system  employs  a  reference  architecture  much  like 
we  have  in  the  design-time  architecture  depicted  in  Figure  3,  which  is  then  instantiated  into 
a  specific  software  product  configuration,  as  suggested  in  the  build-time  architecture  (shown 
in  Figure  4),  then  such  a  reference  or  design-time  architecture  as  we  have  presented  it  here 
effectively  defines  a  SPL  consisting  of  possible  different  system  instantiations  composed 
from  similar  components  instances  (e.g.,  different  but  equivalent  Web  browsers,  word 
processors,  email,  calendaring  applications,  and  relational  database  management  systems). 
Finally,  if  the  SPL  is  based  on  an  OA  that  integrates  software  components  from  multiple 
vendors  or  OSS  components  that  are  subject  to  heterogeneous  licenses,  then  we  have  the 
situation  analogous  to  what  we  have  presented  in  this  paper.  So  SPL  concepts  are 
compatible  with  OA  systems  that  are  composed  from  heterogeneously  licensed 
components. 

Second,  as  already  noted,  software  licenses  represent  a  collection  of  rights  and 
obligations  for  what  can  or  cannot  be  done  with  a  licensed  software  component.  Licenses 
thus  denote  non-functional  requirements  that  apply  to  a  software  systems  or  system 
components  as  intellectual  property  (IP)  during  their  development  and  deployment.  But 
rights  and  obligations  are  not  limited  to  concerns  or  constraints  applicable  only  to  software 
as  IP.  Instead,  they  can  be  written  in  ways  that  stipulate  non-functional  requirements  of 
different  kinds.  Consider,  for  example,  that  desired  or  necessary  software  system  security 
properties  can  also  be  expressed  as  rights  and  obligations  addressing  system 
confidentiality,  integrity,  accountability,  system  availability,  and  assurance  (Breaux  &  Anton, 
2005;  2008). 

Traditionally,  developing  robust  specifications  for  non-functional  software  system 
security  properties  in  natural  language  often  produces  specifications  that  are  ambiguous, 
misleading,  inconsistent  across  system  components,  and  lacking  sufficient  details  (Yau  & 
Chen,  2006).  Using  a  semantic  model  to  formally  specify  the  rights  and  obligations  required 
for  a  software  system  or  component  to  be  secure  (Breaux  &  Anton,  2005;  2008;  Yau  & 

Chen,  2006)  means  that  it  may  be  possible  to  develop  both  a  “security  architecture”  notation 
and  model  specification  that  associates  given  security  rights  and  obligations  across  a 
software  system  or  system  of  systems.  Similarly,  it  suggests  the  possibility  of  developing 
computational  tools  or  interactive  architecture  development  environments  that  can  be  used 
to  specify,  model,  and  analyze  a  software  system’s  security  architecture  at  different  times  in 
its  development — design-time,  build-time,  and  run-time. 

The  approach  we  have  been  developing  for  the  past  few  years  for  modeling  and 
analyzing  software  system  license  architectures  for  OA  systems  (Alspaugh  et  al.,  2009, 
August/September;  Alspaugh  et  al.,  2009b,  May;  Scacchi  &  Alspaugh,  2008),  may  therefore 
be  extendable  to  also  being  able  to  address  OA  systems  with  heterogeneous  “software 
security  license”  rights  and  obligations.  Furthermore,  the  idea  of  common  or  reusable 
software  security  licenses  may  be  analogous  to  the  reusable  security  requirements 
templates  proposed  by  Firesmith  (2004)  at  the  Software  Engineering  Institute. 

Consequently,  such  an  exploration  and  extension  of  the  semantic  software  license 
modeling,  meta-modeling,  and  computational  analysis  tools  to  also  support  software  system 
security  can  be  recognized  as  a  promising  next  stage  of  our  research  studies. 
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Conclusion 


This  paper  discusses  the  roie  of  software  ecosystems  with  heterogeneousiy  iicensed 
components  in  the  deveiopment  and  evoiution  of  OA  systems.  License  rights  and 
obiigations  piay  a  key  roie  in  how  and  why  an  OA  system  evoives  in  its  ecosystem.  We  note 
that  iicense  changes  across  versions  of  components  are  a  characteristic  of  OA  systems  and 
software  ecosystems  with  heterogeneousiy  iicensed  components.  A  structure  for  modeiing 
software  iicenses  and  the  iicense  architecture  of  a  system  and  automated  support  for 
caicuiating  its  rights  and  obiigations  are  needed  in  order  to  manage  a  system’s  evoiution  in 
the  context  of  its  ecosystem.  We  have  outiined  an  approach  for  achieving  these  and 
sketched  how  they  further  the  goai  of  reusing  components  in  deveioping  software-intensive 
systems.  Much  more  work  remains  to  be  done,  but  we  beiieve  this  approach  turns  a  vexing 
probiem  into  one  for  which  workabie  soiutions  can  be  obtained. 
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59  Temple  Place,  Suite  330,  Boston,  MA  021 1 M  307  USA 

It2si| Everyone  Is  permitted  to  copy  and  distribute  verbatim  copies  of  this  license  document,  but  changing 
it  is  not  allowed. 

Preamble 

IsifisilThe  licenses  for  most  software  are  designed  to  take  away  your  freedom  to  share  and  change  it. 
I§iits2|  By  contrast,  the  GNU  General  Public  License  Is  intended  to  guarantee  your  freedom  to  share  and 
change  free  software— to  make  sure  the  software  Is  free  for  all  its  users.  lsitis3|This  General  Public 
License  applies  to  most  of  the  Free  Software  Foundation's  software  and  to  any  other  program  whose 
authors  commit  to  using  It.  (Some  other  Free  Software  Foundation  software  Is  covered  by  the  GNU 
Library  General  Public  License  instead.)  Isifissj  You  can  apply  it  to  your  programs,  too. 

|§H2si|When  we  speak  of  free  software,  we  are  referring  to  freedom,  not  price.  I§if2»2|  Our  General  Public 
Licenses  are  designed  to  make  sure  that  you  have  the  freedom  to  distribute  copies  of  free  software 
(and  charge  for  this  service  if  you  wish),  that  you  receive  source  code  or  can  get  it  if  you  want  it,  that 
you  can  change  the  software  or  use  pieces  of  It  in  new  free  programs;  and  that  you  know  you  can  do 
these  things. 

|§iT3si|To  protect  your  rights,  we  need  to  make  restrictions  that  forbid  anyone  to  deny  you  these  rights 
or  to  ask  you  to  surrender  the  rights.  Isif3s2| These  restrictions  translate  to  certain  responsibilities  for 
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Discussion 


Acquisition  Research  Program;  Creating  S)  tieigj'  for  Informed  Change 
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Software  product  lines  (SPLs)  and  OA 

systems 


•  An  SPL  may  or  may  not  be  an  OA  system 

•  If  SPL  subject  to  single  vendor/proprietary 
license,  then  lock-in  is  possible 

•  If  OA  system  has  design-time  reference 
architecture  and  instantiated  build-time 
architecture,  then  OA  conforms  to  an  SPL 


•  If  SPL  is  based  on  OA  with  heterogeneously 
licensed  components,  then  OA  conforms  to  a 
virtual  SPL,  and  works  with  our  approach. 
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Specifying  and  analyzing  system 
security  requirements  as  “licenses” 


•  Security  capabilities  can  correspond  to  “rights  and 
obligations”  in  licenses 

•  Should  be  possible  to  specify  and  analyze  system 
security  architecture  that  conform  to  a  security 
meta-modei,  much  like  we  do  for  software 
licenses 


•  Should  be  possible  to  develop  computational  tools 
and  development  environments  that  can  analyze 
security  at  design-time,  build-time,  and  run-time, 
as  well  as  when  the  system  evolves 
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Conclusions 


•  Software  component  licenses  and 
heterogeneously  licensed  systems  becoming 
more  widespread  as  we  move  to  OA  software 
ecosystems 

•  Our  approach  and  tools  demonstrate  the 
ability  to  specify,  model,  and  analyze  such 
systems  as  they  evolve,  and  are  subject  to 
diverse  iicenses 


•  Our  approach  is  compatible  with  SPLs  and 
can  be  extended  to  support  system  security 
licenses 
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